From my personal observations I can say, that almost every Internet scene-forum or just dedicated to a special computer platform (Amiga users, and I consider myself to be a one, but not only, are leading here) at one moment has it – a cry for help coming from an ambitious individual, who watched few scene-productions and is more than willing, is eager to commit.... such a one. That person already know that BASIC is evil. As he wants to use an „over-8bit machine” may he could program in C. But he knows there is no way out and he must „possess” the assembly language. But he knows, as everyone, the assembler is the worst BEAST one can tame. Moreover, there are help out there.. So why there is no one who could write such a NORMAL and COMPREHENSIBLE tutorial to help him to rise the coders charts?...

Pardon me, my dear reader, my mocking tone in this introduction but, more or less every six months one can bump into such a topic being opened here or there. Not mentioning that there are at least few answers saying everything can be done in C (6502 CC65-compilator included, etc) or under a supa-dupa optimized BASIC dialect and there are no answers for the question asked... People started to argue which language is, let's say, better over another. Sometimes, someone miraculously shares a few links to tutorials, example source-codes, or proposes which books are helpful and worth to be read. There is also an opinion flying around, that there are „bad coders” keeping with envy theirs secrets and trick. They still want to use them for commercial purposes, thus they are not willing to share their knowledge in an understandable way, not mentioning writing a COMPREHENSIVE (I insist on it) tutorial.

Generally speaking, the situation is hopeless, the World is bad, and because the coders are not helping out, the specific platform is doomed to be soon dead because of lack of new software.

Few days later, our ambitious hero starts writing in „what's that game” topic, "how your retro room looks like”, "how the World would look like if the Commodore would not have went bankrupt".

Well, I have not good news for everyone. The situation will not change (with a new „comprehensible” tutorial and etc.). It will not be better than it is nowadays. There will not be any all-of-a-sudden enlightening lecture, in terms of expectations of our „desperate hero”, no COMPREHENSIBLE book, no recipe for a 100% sure success. The truth is that such miraculous tutorials and books already exist, and there are plenty of them. In our, let ‘say, uncle G**gle reality, everything is within the reach of our hands. The problem is not that the books are too complicated, but in the way how they are used to learn from. There are no god-like methods solving all the encountered problems. Everything needs time and must be understand step by step, sometimes in a slow way, according to one's capabilities of comprehension.

There are materials for the beginners available on the Net showing the most basics how-tos, there are source-codes (some are better some not), there are tutorials, old journal's articles. There are also discussion-forums about coding, when a beginner can ask as many questions as he wishes to (under the condition he knows what is he asking for, and the question has a sense) and recevie the answers (see the prevoius parnethesis). The questions shall be precise.
Many times I witnessed that, once good question asked, the « mighty coders » answered precisely sharing their knowledge and source-codes without hesitation to the one who has shown a dedication, patience, effort and sometimes his own routines. An approach « gimme » or « do for me » is immediately seen and can be easly felt.

Another important condition – the person trying to learn must be serious about it. Nothing happens immediately so the same here, the adept must put a lot of private time and effort. This is a key to the success – own work, reading tutorials, motivation, rereading without better understanding, effort, trying and sometimes(?) sweat. There are no short-cuts, or at least I have never seen a such. What might be helpfull is reading someone's source-codes and running it unde an ASM, changing some parametres and once again assembling and runnig it. Step by step, changing a parameter by parameter.

What a fresh coder should know, or be informed that it is not so rare to develop his own small tools in another programming language (for example BASIC, why not). Such a knowledge and ability may immensly help to write a file converter or a table (sinus or other) generator to mention just a few.

Another thing is to get used to a frequent use of a exadecimal editor, or monitor not mentionning a debugger. Knowing converters, datapackers, music and graphics editor will for sure be a plus.. By all means a coder is not forced to learn all off them to the smalles element, but should know at least how to use some basic functions.

What is important to know is that the assembler alone is not everything. For example, knowing very well a Z80 CPU and a ZX Spectrum is not equvalent to knowing how to code a demo on the Amstrad Schneider CPC or a Gameboy. To do so, the coder should learn, for the considered platform, all its specifications: the memory map, the interrupts, how the Start-Ups should look like, screen and resolution layout, the platform dedicated chipsets (if any) abilities. What may be important, is to test different music players, its raster-time, and replayer capabilities.

The assembler alone is a some kind of a element-assembling-and-configuration tool. Thus it is essential to know the platform we are working on, as good as possible.

Once, the hardware is known, we still have some way to go thru. For example, a coder has to write (or invent) his algorithms on his platform. A nice plasma, how to draw a line, plot a plots, or do a scroll. We will not cover this subject here. Why? And well, there are plenty of already existing algorithmes available on the Net which would give to the adept a proverbal « fishing-rod ». I would cover only my personal methods which may not be the most optimised, thus putting the contraints. And besides that, I wish to develop in our adept some personal creativity, which is a bottomless well full of great ideas.

And how to write such routines... Well, I am sorry, but this is not a subject of this article ;).

The already existing tutorials may give (should give, in fact) a proverbal fishing-rod. The existing source-codes are some kind of bite for a future hungry coder. Once having these to tools – a fishing-rod and bite – and last but not least, a lot of patience, the trainee would learh the art of programming (catching as many fish as he wishes to)..

During one of the copy-parties I was (it was a RetroKomp 2014 party, if I remember correctly), a legendary Polish coder – Polonus/QUARTET- shared with the audience a very meaningful reflection. Ha once read that if a human-being wishes to reach a decent level in a particular, technically advanced domain (a coding for example) one must spent and invest about 10000 (ten thousand) hours. At this occasion, Polonus reveal that once he counted how many hours he did spend. The final calculations gave him about 16000 (sixteen thousand) hours. That's explains his scene results.
We can conclude that no one is born with a special abilities. Indeed, he is gifted, but at the same time he just sit in front of his monitor those 16000 hours. And those were the days, where there were no Internet nor searching-engines.

„Ok, ok...” someone may say „so how to start this game in a serious way?”.

Well, according to my personal experience, the best way is "learning by doing" at the same time not expecting any mind-blowing nor bug-less effects. There will be (!!) a lot of small defeats, eventual machine reboots – that's absolutely normal and must be counted in! But this is a WAY how it is working. True, going forward will be by small steps, but still it is forward. True, this game may look hard, but no one said it will be fast'n'easy. Besides, it is not for everyone neither. Not all of us has a determination, patience or talent for staying and digging in a small mnemonics or hexadecimal numbers. One can be a coder, the other a graphician or a musician... That's the way how it is and this is great!

For those who become patient and persistent will be rewarded by a great satisfaction (personal at first) coming from a working demo effect. The other reward is that once someone got familiar with an assembler language for one of the popular processors, he/she will have an ease to learn faster another programming language and soft/hardware architecture.

Before that none the less, it is advised first to learn the platform we have started to code for. The platforms from the 80s are quite similar so rewriting the routines, between the platforms is not very difficult (thou still a little bit complicated than one may think due to eventual platform-dedicated chips in-procedure-use).

Not being a bare-word, I will use myself as an example here from a past (not far away thou): being a kid I started to learn a 6502 assembly language (Commodore 64/Atari 8-bit computers). I did not manage to do a lot on these, since as soon as the Amiga show up, I quickly moved on to and got hooked by a wonderful and flexible M6800x0 processor. Not so long ago, at the SillyVenture copy party Anno Domini 2012, I was analyzing few Atari 8bit trainers (Stealth, Chuckie Egg for example, the games I always wanted to finish) and guess what? I rapidly refreshed that „rusting”, „old” 6502 assembler.

It got very handful in the fall 2014, when the main organizer of the SillyVenture 2k14 party asked me for a small favor – writing an invitation intro on the Atari Lynx hand-held console, which has as a CPU, a 6502-clone processor (and celebrating the very same year, by the way, its 25th anniversary).

I started to doodle on my own, with small results. I had some 6502 assembler basics, so I decided to contact Sage, the only coder known to me, who coded a very decent demo for Atari Lynx „Lynx Reloaded” (check it for example here: http://www.pouet.net/prod.php?which=10009). Sage was so kind that helped me to configure my assembler/linker/maker on my Linux machine. He helped me with some examples, answered my questions.. So now I could move at a good speed. After few weeks, a SV2k14 Invitation, was ready. Mainly based on Sage's example code, but with mine as well (you may have a look here: http://www.pouet.net/prod.php?which=64409).

As an additional information, I can tell that that Lynx experience made me able to code another Lynx effects and routines. It must be mentioned, that it is also a result of my time invested back in the early days in commodore 64 and/or Atari 8bit 6502 assembler. And of course my Amiga demo coding experience. The mechanism which for sure was working was „Ha! It reminds me something...” or „I know it already...” And of course the help I was given by Sage - I knew I did everything on Lynx to find out on my own, I knew what I was asking Sage for, I did check what I could”. Sage from his side was fully engaged in the project as well, and the Invitation was finished and released on time.

„Ok, ok, ok... I got it. But at the end... how is it?...” perhaps one of the readers (perhaps you) may ask...

And well... It is a for sure a case-by-case basis, but in „general”, the rules might be written as follows (in my personal opinion):

1. Find and gather as many material as possible available - download from the Net, buy if there is a paper book in your reach, download scans, tutorials, articles available in the fanzines or paper magazines, publications, curses, sourcecodes.
   Look them through, not going into the details too deeply to organize them depending on the difficulty, advancement level.
   Next, start from the easiest one, reading them not once, but three four or more times... If some parts are still difficult – skip them at this time – there will be time you will got them at the first glance (almost).
   What is also worth to mention – to look for old disk magazines. Very often they contained tutorials with sourcecodes. They are very good as well, since were written by, at that time, teen-scenners without any high engineering way of approach. So in a more comprehensive way, so to speak.
2. Gather and make run all the necessary tools...i.e. Assmeblers (yes, few assemblers in, order to choose the most friendly), packers/depackers, crunchers/decrunchers, graphics and music converters, memory and disk monitors and emulators (yes, it is very helpful as well), and so on...
   Read their instructions (sometimes added, sometimes available on Internet sites), try them all to learn their functionalities.
3. A good knowledge (or even a friendship) with a debugger would be a good assets. Also a good idea is to know how to use an Action Replay cartridge's built-in monitor or/and debugger. Thus, one may freeze a running game or demo and look into the code from freezer's level. Changing some register or memory's values, mnemonics, would give a great area to learn the code. Trying to change some values (text on the screen, colors’ values, number of lives or the energy), to block something, to break, to freeze a routine, to make „some mess” would a good lesson. Change the values in the memory and perhaps on the disk (making previously a safe, back-up copy).
4. If possible, to read all gathered sources, zines, materials – the memory map, CPU and its mnemonics descriptions, addressing modes, cycles consumptions, tips and tricks. It is a good manner to make personal by-side notes. In that way it is easier to remember where to look for the information.
   What is not less important, is to write small routines, in order to learn and see how the assembler instruction works. Still remembering to follow its execution under a debugger. Look into the memory addresses concerned by these instructions, how the code works, looks like in to the memory and what does. Test the machine dedicated custom chips (COPPER for example).
5. Download, print any code tutorials one bump into, examples how the game-trainers are done, what do they do and how do they „patch” the memory in a safe way. It also helps to make a difference between a code and data. It is a pleasant and fruitful work to understand and next do our own trainer. It gives us a satisfaction as well.
6. Run all the examples you have, if possible. Analyze them carefully in a step-by-step manner, and, what is crucial, modify them, taking a note what the modification does/did. Repeat the latter step with other commands, mnemonics, values. Still taking notes about what has been „discovered”.
7. After playing enuff with (demo) effects examples – change the focus on the "start-up" examples trying to write your own. Thus writing your very own test-environment which would become perhaps a future demo-environment.
8. Music players. Download some and choose the best which fits you. Integrate it with your freshly-written „start-up” demo-environment. Hereby, please, fear not my friend. Using a player already written by other coders is a common and normal practice. So-called music players were usually bundled with a music editors it was used in. To know the player, is to learn the interrupts, which are used by the music player.
9. A good asset is the knowledge of a high-level language (C, BASIC or Pascal to name just a few). This knowledge will help us when a special demo-data, tables need to be generated. For example to be used in a graphics effect.
10. Analyze the code of some simple effects, learn how the graphic screen is organized, and how is used, learn how to use the different resolutions, how and where to set the color-palette, how to put on the screen a single dot, or few of them, how to draw a line, what is being used for such effects. Generate a simple sinus/cosinus table and try to use it. Write a simple one-effect intro (do not release it), write a (sinus) scroller, bouncing sprites perhaps, copper-bars, use a music-player routine, put a static gfx/logo. It may look like a waste of time, but it is not. You will learn how to organize the data in the memory, how do you cope with the code, and, what is the best, on this base, you will have an open door to code better, more sophisticated productions. Perhaps like a dentro or maybe the future demo :).
11. One of the pleasant (and sometimes frustrating as well) part of learning process is to watch (new) demos and to understand, wonder „how it was done”. If decided so, try to write a similar (better) effect. It may be not too easy at the beginning, thus you may ask someone on the forums. You may dissasemble the demoeffect in question as well and look how is it done. If you go to this direction, write a final, your proper version. Never rip anyone’s work.
12. Visit and read coder-oriented discussion-forums, lurk in to the achieve, look thru some interesting topics.
13. Write, write and once again write. Write your own, even simple effect routines as often as possible, change the parameters, test them, change the modulo (sometimes you may be surprised what it can done).
14. Get a hand on the official books treating about graphics procedures and effect. Make you familiar with mathematical formulas of rotating, shading, perspective. There are plenty of these information in the Net.
15. Go to the copy-party (yes!). Make friends with other coders, share some experience (ad a beer, more many of them). Ask as many questions as you have (what tools is he using, what should be avoided and etc). Share your experience as well. Be opened and share your knowledge....

...and after coming back home, roll your sleeves up, sit down in front of your work environment, and write your own compo-entry... for the next copy-party you will be attending to. :)

In other words: there is no other way than "you have to work with your hands (and get them dirty)".

Good luck.

Sachy / Wanted Team ^ Resistance ^ Lamers
(November 2014)

Translation: Sim / Wanted Team, Lamers, Resistance, Titan...